Subject: Summary of MIB working sessions at AIW7

From: "Peter W. Gayek" <[email-masked]>
Date: Fri, 19 May 95 11:08:47 EDT

Below is a list of MIB changes agreed upon and issues discussed at
AIW7 two weeks ago in San Jose.  Shannon will be following up this
note with the schedule we adopted, and any other information that
needs to be added.  As always, comments and corrections are welcome.

Items are generally listed in the order encountered in the MIB.
Section and/or page numbers refer to draft-ietf-dlswmib-mib-04.txt.
I have tried to capture significant discussions even if they resulted
in no MIB change.  This provides some history as well as background for
non-attendees, and may save us rehashing the same questions in the
future.  I haven't listed some changes that were purely editorial.

- Sec 4.6.1
  We discussed the problem of correlating transport address to the
  SNMP transport address.  The consensus was to drop consideration
  of this problem for now (my interpretation - for the V1 MIB).
  Some folks viewed this as a problem that exists today in other
  settings, and network managers use network maps to solve it.

- Sec 4.6.2
  There was general approval of the recent change that the MIB not
  dictate (with explicit timers etc.) how an implementation should
  reduce broadcasts of runtime capex messages.

- p.12 NBName convention
  Should be octet string, to accomodate byte values that are not
  displayable ASCII characters.

- p.13 DlcType convention
  We agreed QLLC should be added, and that LLC over frame relay
  should not get its own value (it's just LLC).

- p.16 dlswStatus
  We agreed this should stay one object instead of splitting into Admin
  and Oper versions.  Reasons:  (1) there is no significant time lag
  between a set to change state and the resulting state change, and
  (2) the intermediate state is discernable by querying other objects
  (e.g., circuit and TC states).

- p.17 dlswVirtualSegmentLFSize
  DEFVAL should be the maximum value (64K).

- p.17 dlswResource*Exclusivity
  Could be moved to TConfig table, but the general feeling was to leave
  it global unless someone has a strong requirement otherwise.

- pp.18-19 dlswTConnStatFC*, p. 36 dlswTConnOperFlowCntl*
  Move these four objects to the circuit table.  Reasons:  (1) Very
  difficult for some to implement  (2) Placement rationale that you
  could infer box/partner box status was somewhat questionable,
  (3) even without history, useful info can be derived by summing up
  circuit-level counters.

- pp.19-24 dlswTConnConfig*, transport-specific objects
  The consensus was to have parallel tables with the same index, for
  objects that make more sense when treated as transport-specific.
  This made for more understandable objects and a more extendable MIB.
  For the V1 MIB, this means adding a table dlswTConnConfigTCP.  The
  following objects were identified to be moved to this table:
    dlswTConnConfigLocalTAddr      (local IP address)
    dlswTConnConfigRemoteTAddr     (remote IP address)
    dlswTConnConfigKeepAliveInt    (TCP keep alive interval)
    dlswTConnConfigVirtualChannels (preferred # TCP conn's, DEFVAL 2)
    dlswTConnConfigRecvWindowSize  (MSS, should have DEFVAL 4K)

- p.21 dlswTConnConfigRemoteTaddrMask
  We had a VERY long discussion on whether to allow a TConnConfig entry
  to represent multiple partners.  The problem centers around how to
  know the order in which individual vs. masked entries are used, and
  how to configure the box deterministically.  Ideas and corresponding
  problems were:
   1) Index by TDomain, inverse mask.  Hard to be transport-independent,
      not flexible.
   2) Arbitrary order with a separate read table (like directory).  Can't
      configure the box.
   3) Don't allow row create if mask set.  Restrictive.
   4) Add new object for order/priority.  Complicated to implement.

  Resolution for now (still an open issue):
  - Delete the mask object.  Have 0 or 1 global rows, and 0-n individual
    rows.
  - Add an include/exclude flag to individual rows, allowing specification
    of disallowed partners.  This isn't needed for the global row, because
    you can exclude all but specified partners by not having the global row.
  - I lied above.  To allow multiple local transport addresses within a
    transport domain, we could have 0 or 1 global row per local transport
    address.  So we now need a global/individual indicator to replace
    the mask rather than using a fixed index value for the global row.

- p.20 dlswTConnConfigIndex
  Yes we need the rule that the index can't be reused.

- p.21 dlswTConnConfigSetupType
  Add a value 5 meaning "not allowed" or "exclude" as described above.

- p.22 dlswTConnConfigSapList, p.38 dlswIfSapList
  DEFVAL should be SAPs 0,4,8,C.

- p.22 dlswTConnConfigInitCirRecvWndw
  This and all pacing window sizes in the MIB should allow up to the
  protocol's max value of 64K.  There are a bunch of these objects in
  the circuit table (I won't bother to list them).

- p.27 dlswTConnOperState, ...ConfigIndex
  We discussed the rules for changing configured parameters and the
  issues involved in pointing back from TConnOper to TConnConfig.
  The consensus was to drop the rule about zeroing TConnOperConfigIndex
  when TConnConfig is modified (only do it when the latter is deleted).
  Add a "last modified time" object to TConnConfig so the mgt station
  can tell when a config parameter MAY have been invalidated.

- p.27 dlswTConnOperKeepAliveInt, ...VirtualChannels
  We agreed these should move to a TCP-specific oper table.  We did
  not decide on the indexing of this new table, but some options are
  a common index to TConnOper, or an OID.

- p. 32 dlswTConnOperDiscReason
  Delete values 2 and 3 (not mutually exclusive with other values).  Add
  a new object for # circuits active when TC disconnected (or could be a
  simple state idle v. busy).

- p.34 dlswTConnOperICRexRcvds, p.35 dlswTConnOperNRexRcvds
  Drop the word "valid" from the description.

- p.35 dlswTConnOperCirCreates
  Should be when circuits entered "established" state.

- p.39 comment table below dlswDirCache
  User-configured remote entries cannot have a null location, but can
  have the status reachable/not reachable.  The consensus was also to
  add a table entry object for these status values.

- p.40 dlswDirMacIndex, pp. 45-48 locate tables
  We had the same discussion for the directory as we had for TConnConfig,
  i.e., how to configure a mix of wildcard and unique entries and know
  the order in which the implementation would use them.  The consensus
  was for now to leave the index as an integer and still have the locate
  tables, but impose a rule that implementations must observe a "most
  specific match first" policy in using configured directory rows.
  Stated another way, an implementation must use an implicit inverse
  mask ordering when building a reply in the locate tables.

- p.41 dlswDirMacEntryType
  Add value for "user configured private".   This will be valid only for
  configured local entries.

- pp.42-45 dlswDirNBTable
  Ditto the last 3 items.

- pp.48-49 dlswDirSearch*
  Some felt this type of function was pretty fancy for a standard MIB,
  and should be deleted.  This is an open question.  If we decide to
  delete this function, the two objects dlswDirExplore*Timer could also
  be deleted, so we need to decide this also.  They existed primarily
  so the NMS could know when it was safe to query the directory for
  search results.

- p.53 dlswCircuitS1RouteInfo
  Should accomodate 30-byte RI field.

- p.55 dlswCircuitState
  Add text to allow a write to take down a circuit.  I think we discussed
  what values should be writable, but I don't have good notes on it.
  Perhaps we should allow only "disconnected" or "disconnectPending",
  or maybe there should be a new object to trigger circuit takedown.

- p.57-58 dlswCircuitSenseCode
  Reorder so ones the protocol can use will be at the top.  Also, add object
  for remote disconnect reason.  Although the latter is a version 2 protocol
  item, the RIG approved it at the AIW so we added it to the MIB.

The MIB walkthrough ended somewhere around the dlswSdlcLsTable.   I do not
believe we discussed traps or compliance statements.

SUMMARY OF OPEN ISSUES
Everyone, please post your views as soon as possible on the following:

1) Are we OK with the resolution of the mask issue for TConnConfig?

2) What indexing should be used for the TCP-specific TConnOper table?

3) Are we OK with the resolution of the indexing/configuring issue for
   the MAC address and NetBIOS name directories?

4) Should the standard MIB include the directory search function?  If not,
   should we still keep the objects dlswDirExplore*Timer?

5) What should the rules be for writing to dlswCircuitState?

Peter Gayek
IBM Corp.